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SPECIFICATION 



TITLE OF INVENTION 
ON-DEMAND ADDRESS POOLS 

Cross Reference to Related Applications 

[0001] This application is related to the following: 
U.S. Patent Application Serial No. 09/765,981, filed January 19, 2001 in the name of 
inventor Pumam Sheth, entitled "IP Pool Management Utilizing an IP Pool MIB", 
Attorney Docket No. CISCO-3189, commonly assigned herewith. 



FIELD OF THE INVENTION 
[0002] The present invention relates to the field of data communications. More 
particularly, the present invention relates to a system and method for on-demand address 
pools. 



BACKGROUND OF THE INVENTION 



[0003] The growth of the Internet appears to be exponential. Tens of thousands 
of networks are now cormected to the Internet, and the number is close to doubling every 
year. Unfortunately, however, Internet Protocol (IP) addresses are not infinite and it is 
rather expensive to procure more EP addresses. With the increase in the number of users 
of the Internet, Telcos (Telecommunication companies) and ISPs (Internet Service 
Providers) are faced with an increasing shortage of IP addresses. 
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[0004] Each service to which a user may be connected has an associated LP 
address space. That is, a certain range of addresses may address that space. The range 
may be contiguous, discontiguous, or a combination of both. For example, Corp A may 
have an intranet service having all IP addresses which start with "10.1" -- this may be 
denoted "lO.l.x.x" where x can be any value. It may also be denoted "10.1.0.0; 
255.255.0.0" where "10.1.0.0" represents the IP address and "255.255.0.0" represents the 
subnet mask. Those of skill in the art will recognize that a 255 in the subnet mask field 
represents a binary 1111 1111 and amounts to a requirement that the corresponding field 
of the IP address must match bit for bit in order to achieve a match. On the other hand, a 
0 in the subnet mask field represents a binary 0000 0000 and amounts to no requirement 
for any match. For example, a service having an address space of "0.0.0.0; 0.0.0.0" 
represents the Internet, i.e., all EP addresses are within this space. Note that since the 
subnet mask is 0.0.0.0 the IP address could be set to any value and it would yield the 
same result. 

[0005] The Dynamic Host Configuration Protocol (DHCP) has been developed 
to provide an automated assignment of IP addresses and to help solve the shortage of IP 
addresses. Conventional DHCP operation is as follows: When a DHCP client computer 
attempts an Internet connection, it broadcasts a DHCP request asking for any DHCP 
server on the network to provide it with an IP address and configuration parameters. A 
DHCP server on the network that is authorized to configure this client will offer an IP 
address by sending a reply to the client. Upon receiving this offer, the client may decide 
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to accept it or wait for additional offers from other DHCP servers on the network. At the 
end, the cUent chooses and accepts one offer, and the chosen DHCP server sends an 
acknowledgement with the offered IP address having an associated "lease" time (and any 
other configuration parameters the client might have requested). During the lifetime of 
the lease, the client will repeatedly ask the server to renew. If the client chooses not to 
renew or if the client machine is shut down, the lease eventually expires. Once the lease 
expires, the IP address can be "recycled" and given to another machine. 

[0006] The RADIUS (Remote Authentication Dial In User Service) 
protocol is typically used to authenticate a user and to associate the user with a remote 
domain and associated routing table. Like DHCP, RADIUS can also be used to assign an 
IP address to a remote user. 

[0007] Point-to-Point Protocol (PPP) sessions are typically terminated on a 
home gateway, at a remote domain such as a virtual private network (VPN) and the 
owner of the remote domain is responsible for address assignment. In this case, a 
Network Access Server (NAS) is configured so as to implement DHCP-like functionahty 
with IP address pools so as to dynamically allocate IP addresses. The NAS distributes IP 
addresses to users (end-users of the Telco or ISP) when the users log-in. The NAS also 
revokes IP addresses when the users log-out, making those IP addresses available to other 
users. 
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[0008] The network edge is the point where customer traffic enters a service 
provider's network. Traffic can arrive at the edge via access technologies including dial, 
IP, ATM, Frame Relay, leased line, wireless, Digital Subscriber Line (xDSL) and cable. 
An edge switch or edge router aggregates traffic from all or some of these access 
interfaces and forwards packets over a multiplexed packet network core. 

[0009] Service providers have begun handhng management of IP addresses for 
owners of remote domains. In these cases, PPP sessions are terminated at the service 
provider's premises on an edge router. The owner of the remote domain provides the 
service provider with a pool of IP addresses to manage on behalf of the remote domain. 
An edge router of the service provider assigns IP addresses to remote users (users of the 
remote domain) as needed. Whenever an edge router assigns an IP address to a remote 
user, it must insert a route to that user in a routing table designated for the remote 
domain. This update must be propagated to corresponding routing tables in each edge 
router in the network. This is explained below in more detail with reference to FIG. 1. 

[0010] Figure 1 is a flow diagram that illustrates a typical method for allocating 
IP addresses. At 100, a service provider receives a pool of IP addresses from an owner of 
a remote domain such as a virtual private network. At 105, each pool of IP addresses is 
divided into per-remote domain local IP address pools on each edge router that is 
configured to accept PPP sessions from remote users of the remote domain. At 110, a 
determination is made regarding whether an IP address from a remote user has been 
received. If an IP address from a remote user has been received, at 1 15 an unused IP 
address from a local IP address pool designated for the remote domain being connected to 
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is assigned to the remote user. At 120, a route to the remote user is inserted into the 
corresponding edge router routing table. If an IP address from a remote user has not been 
received, at 125 a determination is made regarding whether an IP address has been 
returned. If an IP address has been returned, the IP address is returned back to its 
designated IP address pool at 130 and the route to the remote user is removed from the 
corresponding routing table at 135. 

[0011] However, maintaining routing information for each IP address is 
expensive with respect to network bandwidth consumption because each time an address 
is added or removed, the event must be broadcast so that other network entities know 
which edge router is handling the address. Moreover, this problem of bandwidth 
consumption increases and becomes more acute during peak use hours. Additionally, the 
routing tables grow larger and more difficult to manage as the size of the network grows. 

[0012] An improvement is made possible by statically configuring local IP 
address pools on each edge router. Each edge router includes at least one local IP address 
pool designated for a remote domain. Each edge router also includes a routing table for 
each remote domain supported by the edge router. Local IP address pools are divided 
into groups of contiguous IP addresses or subnets. Summarized routes corresponding to 
all subnets in an address pool are inserted into the edge router routing table associated 
with the pool. Local IP address pools allow relatively efficient route summarization 
because fewer routing table updates are required. This explained below in more detail 
with reference to FIG. 2. 
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[0013] Figure 2 is a flow diagram that illustrates an improved method for 
allocating IP addresses using statically configured local IP address pools. At 200, a 
service provider receives a pool of IP addresses from a remote domain to manage on 
behalf of the remote domain. At 205, each pool of IP addresses is divided into per- 
remote domain local IP address pools on each edge router that is configured to accept 
PPP sessions from remote users of the remote domain. At 210, summarized routes 
corresponding to subnets in the address pool are statically inserted into the routing table 
associated with the pool. At 215, a determination is made regarding whether an IP 
address request has been received from a remote user. If a an IP address request has been 
received, at 220 an unused IP address is assigned from a local IP address pool designated 
for the remote domain being connected to. If an IP address has not been received, at 225 
a determination is made regarding whether an IP address has been retumed. If an IP 
address has been retumed, at 230 the TP address is retumed to its designated IP address 
pool. 

[0014] Unfortunately, statically configured local IP address pools have their 
own disadvantages. It is possible to ovemtilize IP addresses for one edge router-remote 
domain combination while simultaneously undemtilizing IP addresses for another edge 
router configured to accept connections for the same remote domain. For example, 
suppose edge router 1 and edge router 2 are configured with 10 IP addresses each for 
connections to a particular remote domain. Once edge router 1 allocates all 10 ff 
addresses, fiirther requests to edge router 1 from remote users of the remote domain will 
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result in denial of service, even if edge router 2 has allocated only 2 of its 10 IP 
addresses. 



[0015] As mentioned above, both the DHCP and RADIUS protocols can be 
used to assign IP addresses. However, these protocols assign a host address to a remote 
user. The edge router can be configured to autosummarize the host routes before 
redistributing them. Unfortunately, route summarization is inefficient in this case 
because remote users log on and off indeterminately, making it difficult to have a 
contiguous set of IP addresses that can be summarized. Furthermore, it takes time to 
propagate a newly inserted route to all edge routers. A remote user has limited 
connectivity during this period. Another disadvantage is that updates must be sent to 
each edge router whenever a remote user logs on or off 

[0016] What is needed is a solution that provides dynamic and relatively 
efficient allocation of remote domain IP addresses between one or more edge routers. A 
further need exists for such a solution that uses open and well-understood standards. 
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BRIEF DESCRIPTION OF THE INVENTION 



[0017] A method for on-demand management of Internet Protocol (IP) address 
pools includes allocating an unused IP address from a local IP address pool designated 
for a remote domain if a request to connect to the remote domain is received and 
deallocating an IP address back to the local IP address pool if the IP address is unused. 
The method also includes apportioning one or more of the at least one subnet between the 
global IP address pool and the local IP address pool based upon utilization of the local IP 
address pool. The local IP address pool includes one or more of at least one subnet 
obtained from a global IP address pool and each subnet specifies a contiguous set of one 
or more IP addresses. An apparatus for on-demand management of Internet Protocol (IP) 
address pools includes an allocator to allocate an unused IP address from a local IP 
address pool designated for a remote domain if a request to connect to the remote domain 
is received and a deallocator to deallocate an IP address back to the local IP address pool 
if the IP address is unused. The apparatus also includes a monitor to apportion one or 
more of the at least one subnet between the global IP address pool and the local IP 
address pool based upon utilization of the local IP address pool. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

[0018] The accompanying drawings, which are incorporated into and constitute 
a part of this specification, illustrate one or more embodiments of the present invention 
and, together with the detailed description, serve to explain the principles and 
implementations of the invention. 

[0019] In the drawings: 

[0020] FIG. 1 is a flow diagram that illustrates a method for managing remote 
domain IP address pools. 

[0021] FIG. 2 is a flow diagram that illustrates a method for managing remote 
domain IP address pools that includes route summarization using statically configured 
local IP address pools. 

[0022] FIG. 3 is a block diagram that illustrates an apparatus for on-demand IP 
address management in accordance with one embodiment of the present invention. 

[0023] FIG. 4 is a block diagram that illustrates an apparatus for on-demand IP 
address management using the RADIUS protocol in accordance with one embodiment of 
the present invention. 
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[0024] FIG. 5 is a block diagram that illustrates on-demand IP address 
management in accordance with one embodiment of the present invention. 



[0025] FIG. 6 is a block diagram that illustrates an apparatus for on-demand IP 
address management using the DHCP protocol in accordance with one embodiment of 
the present invention. 

[0026] . FIG. 7 is a block diagram that illustrates on-demand IP address 
management in accordance with one embodiment of the present invention. 

[0027] FIG. 8 is a block diagram that illustrates an edge router configured for 
on-demand IP address management in accordance with one embodiment of the present 
invention. 

[0028] FIG. 9 is a block diagram that illustrates the contents of a local IP 
address pool in accordance with one embodiment of the present invention. 

[0029] FIG. 10 is a block diagram that illustrates the contents of a local IP 
address pool in accordance with one embodiment of the present invention. 

[0030] FIG. 1 1 is a flow diagram that illustrates a method for on-demand IP 
address management in accordance with one embodiment of the present invention. 
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[0031] FIG. 12 is a flow diagram that illustrates a method for configuring a 
global IP address pool and local IP address pools with per-remote domain subnet 
allocations in accordance with one embodiment of the present invention. 

[0032] FIG. 13 is a flow diagram that illustrates a method for dynamically 
allocating and deallocating subnets between a global IP address pool and a local IP 
address pool based upon local IP address pool utilization in accordance with one 
embodiment of the present invention. 

[0033] FIG. 14 is a flow diagram that illustrates a method for dynamically 
allocating and deallocating subnets between a global IP address pool and a local IP 
address pool based upon local IP address pool utihzation in accordance with one 
embodiment of the present invention. 
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DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT 



[0034] Embodiments of the present invention are described herein in the context 
of a system and method for on-demand address pools. Those of ordinary skill in the art 
will realize that the following detailed description of the present invention is illustrative 
only and is not intended to be in any way limiting. Other embodiments of the present 
invention will readily suggest themselves to such skilled persons having the benefit of 
this disclosure. Reference will now be made in detail to implementations of the present 
invention as illustrated in the accompanying drawings. The same reference indicators 
will be used throughout the drawings and the following detailed description to refer to the 
same or Hke parts. 

[0035] In the interest of clarity, not all of the routine features of the 
implementations described herein are shown and described. It will, of course, be 
appreciated that in the development of any such actual implementation, numerous 
implementation-specific decisions must be made in order to achieve the developer's 
specific goals, such as compliance with application- and business-related constraints, and 
that these specific goals will vary from one implementation to another and from one 
developer to another. Moreover, it will be appreciated that such a development effort 
might be complex and time-consuming, but would nevertheless be a routine undertaking 
of engineering for those of ordinary skill in the art having the benefit of this disclosure. 
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[0036] In the context of the present invention, the term ''network" includes local 
area networks, wide area networks, the Internet, cable television systems, telephone 
systems, wireless telecommunications systems, fiber optic networks, ATM networks, 
frame relay networks, satellite communications systems, and the like. Such networks are 
well known in the art and consequently are not further described here. 

[0037] In accordance with one embodiment of the present invention, the 
components, processes and/or data structures may be implemented using C or C++ 
programs running on high performance computers (such as an Enterprise 2000™ server 
running Sun Solaris™ as its operating system. The Enterprise 2000™ server and Sun 
Solaris™ operating system are products available from Sun Microsystems, Inc. of 
Mountain View, California). Different implementations may be used and may include 
other types of operating systems, computing platforms, computer programs, firmware, 
computer languages and/or general-purpose machines. In addition, those of ordinary skill 
in the art will recognize that devices of a less general purpose nature, such as hardwired 
devices, field programmable gate arrays (FPGAs), application specific integrated circuits 
(ASICs), or the like, may also be used without departing from the scope and spirit of the 
inventive concepts disclosed herein. 

[0038] The authentication, authorization and accounting (AAA) service 
performs user authentication, user authorization and user accounting fimctions. It may be 
a Cisco ACS™ product such as Cisco Secure™, available from Cisco Systems, Inc. of 
San Jose, California, or an equivalent product. In accordance with a presently preferred 
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embodiment of the present invention, the Remote Authentication Dial-hi User Service 
(RADIUS) protocol is used as the communication protocol for carrying AAA 
information. RADIUS is an Internet standard track protocol for carrying authentication, 
authorization, accounting and configuration information between devices that desire to 
authenticate their links and a shared AAA or AAA proxy service. Those of ordinary skill 
in the art will realize that other authentication protocols such as TACACS+ (Tools & 
Algorithms for Construction and Analysis of Systems) or DIAMETER can be used as 
acceptable authentication communications links between the various communications 
devices that encompass the data communication network and still be within the inventive 
concepts disclosed herein. RADIUS, TACAS+, and DIAMETER are protocols known 
by those of ordinary skill in the art and thus, will not be further discussed other than in 
the context of the present invention in order to avoid over-complicating the disclosure. 

[0039] According to embodiments of the present invention, a global IP address 
pool maintains a pool or block of IP addresses for one or more remote domains. Each 
pool is divided into subnets and these subnets are assigned to edge routers when 
requested. An edge router includes at least one local IP address pool configured for at 
least one remote domain supported by the edge router. The edge router makes subnet 
requests and releases subnets based upon local IP address pool utilization. Dynamic 
allocation of subnets between local IP address pools allows relatively efficient route 
summarization as well as relatively efficient utilization of a remote domain's IP address 
space. 
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[0040] Turning now to FIG. 3, a block diagram that illustrates an apparatus for 
on-demand IP address management in accordance with one embodiment of the present 
invention is presented. Figure 3 includes edge router 300 and edge router 305. Each 
edge router (300, 305) includes a routing table storage (310, 315) coupled to a local IP 
address pools monitor (320, 325) and a global IP address pool interface (330, 335) 
coupled to the local IP address pools monitor (320, 325) and a global IP address pool 
manager 340. Each edge router (300, 305) also includes an IP address pool configurer 
(345, 350) coupled to the routing table storage (310, 315) and to a local IP address pools 
storage (345, 350). Local IP address pools storage (345, 350) is coupled to the local IP 
address pools monitor (320, 325) and to a local IP address manager (365, 370). Local JP 
address manager (365, 370) is coupled to network 375. Global IP address pool manager 
340 is coupled to global IP address pool 380, which includes global per-remote domain 
IP address pool information. 

[0041] One or more of remote domains 382-392 provide a service provider with 
a set of IP addresses for the service provider to manage on behalf of the remote domains. 
The number of remote domains illustrated is not intended to be in any way limiting. The 
service provider stores information about these IP addresses in global IP address pool 
380. The service provider may also configure edge router (300, 305) with one or more 
subnets for one or more remote domains. In operation, edge router (300, 305) receives a 
PPP connection request and allocates an IP address from the local DP address pool 
designated for the remote domain being connected to. The IP address is returned to the 
local IP address pool when the PPP session ends. Local IP address pools monitor (320, 
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325) monitors local IP address pool utilization. Local BP address pools monitor (320, 
325) issues a request for an additional subnet when local IP address pool utilization 
exceeds a high watermark. Local IP address pools monitor (320, 325) also releases a 
subnet when local IP address pool utilization drops below a low watermark. 

[0042] Figures 4 and 5 illustrate on-demand IP address management using the 
RADIUS protocol. Figures 6 and 7 illustrate on-demand IP address management using 
the DHCP protocol. Those of ordinary skill in the art will realize that other 
authentication protocols can be used as acceptable authentication communications links 
between the various communications devices that encompass the data communication 
network and still be within the inventive concepts disclosed herein. 

[0043] Turning now to FIG. 4, a block diagram that illustrates an apparatus for 
on-demand IP address management using the RADIUS protocol in accordance with one 
embodiment of the present invention is presented. A Global IP address pool 400 is 
maintained in AAA server 405. Edge routers 410 and 415 communicate with the AAA 
server 405 via AAA proxies 420 and 425. 

[0044] Turning now to FIG. 5, a block diagram that illustrates on-demand IP 
address management in accordance with one embodiment of the present invention is 
presented. The process used to obtain an additional subnet is illustrated beginning with 
reference numeral 500. At 500, the local IP address pool manager issues a subnet 
request. The request includes a remote domain ID, a NAS port and a requested subnet 
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size. At 505, the AAA client receives the request, puts the request in RADIUS format 
and sends the request to the AAA server. At 5 10, the AAA server responds with a subnet 
allocation packet that includes the remote domain ID, NAS port, allocated subnet size 
and allocated subnet address. At 515, the AAA chent receives the subnet allocation 
packet, extracts the allocated subnet and sends it to the local IP address pool manager. 

[0045] Still referring to FIG. 5, the process used to release a subnet is illustrated 
beginning with reference numeral 520. At 520, a packet including the remote domain ID, 
NAS port, subnet size and subnet address are sent to the AAA client. At 525, the AAA 
client receives the packet, puts the packet in RADIUS format and sends the subnet 
release packet to the AAA server. At 530, the AAA server issues an acknowledge 
packet. 

[0046] Turning now to FIG. 6, a block diagram that illustrates an apparatus for 
on-demand IP address management using the DHCP protocol in accordance with one 
embodiment of the present invention is presented. The global IP address pool 600 is 
maintained in DHCP server 605. Edge routers 610 and 615 communicate with DHCP 
server 605 via Ring Access Controller (RAC) clients 620 and 625. 

[0047] Turning now to FIG. 7, a block diagram that illustrates on-demand IP 
address management in accordance with one embodiment of the present invention is 
presented. The process used to obtain a subnet is illustrated beginning with reference 
numeral 700. At 700, the local IP address pool manager issues a subnet request. The 
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request includes a remote domain ID, edge router address and requested subnet size. At 
705, the RAC client receives the request, puts the request in DHCP format and sends a 
DHCP Discover packet to the DHCP server. Upon receipt of the DHCP discover packet, 
the DHCP server uses the remote domain ID, edge router address and requested subnet 
size in the DHCP discover packet to obtain a subnet from the global IP address pool. At 
710, the DHCP server responds with a DHCP Offer packet that includes the offered 
remote domain ID, edge router address, subnet address and subnet size. At 715, the RAC 
client sends a DHCP request packet that includes the offered remote domain ED, edge 
router address, subnet address and subnet size. At 720, the RAC client receives an 
acknowledge packet from the DHCP server. At 725, the RAC client extracts the 
allocated subnet and sends it to the local IP address pool manager. 

[0048] Still referring to FIG. 7, the process used to release a subnet is illustrated 
beginning with reference numeral 730. At 730, a packet including the remote domain ID, 
edge router address, subnet address and subnet size is sent to the RAC cUent. At 735, the 
RAC client receives the packet, puts the packet in DHCP format and sends the DHCP 
release packet to the DHCP server. Processing continues without waiting for an 
acknowledgement packet. 

[0049] Turning now to FIG. 8, a block diagram that illustrates an edge router 
configured for on-demand IP address management in accordance with one embodiment 
of the present invention is presented. Figure 8 provides more detail for reference 
numerals 300 and 305 of FIG. 3, reference numerals 410 and 415 of FIG. 4, and reference 
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numerals 610 and 615 of FIG. 6. Edge router 800 includes a global IP address pool 
interface 805 coupled to a global IP address pool manager 810 and a local IP address 
pools manager 815. The local IP pools manager 815 is coupled to a local IP address pool 
storage 820 and a routing table storage 825. Local IP address pools manager 815 
includes an IP address pool configurer 830, a local IP address manager 835 and a local LP 
address pools monitor 840. The local IP address manager 835 includes an IP address 
allocator 850 and an IP address deallocator 845. The local IP address pools monitor 840 
includes a subnet requester 855 coupled to the global IP address pool interface 805 and to 
a utilization assessor 860. The utilization assessor 860 is coupled to a subnet returner 865 
and the local IP address pools storage 820. The local EP address pools monitor 840 also 
includes a subnet receiver 870 coupled to the global DP address pool interface 805, the 
local IP address pools storage 820 and the routing table storage 825. 

[0050] Local IP address pools storage 820 includes at least one local IP address 
pool that is designated for a particular remote domain. As shown in FIG. 8, local IP 
address pool la (872) and IB (874) are designated for remote domain 1 (876), while local 
IP address pools 2 (878), 3 (880), 4 (882), 5 (884) and N (886) are designated for remote 
domains 888, 890, 892, 894 and 896, respectively. Similarly, routing table storage 825 
includes at least one routing table that is designated for a particular remote domain. As 
shown in FIG. 8, routing tables 812, 822, 842, 852 and 862 are designated for remote 
domains 876, 888, 890, 892, 894 and 896, respectively. 
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[0051] In operation, IP address pool configurer 830 configures at least one local 
IP address pool and associated routing table. IP address allocator 850 receives a PPP 
session request. IP address allocator 850 allocates an IP address from the local IP address 
pool designated for the remote domain being connected to. IP address deallocator 845 
releases the IP address when the PPP session ends. 

[0052] Still referring to FIG. 8, local IP address monitor 840 monitors local IP 
address pool utilization and attempts to modify the size or number of subnets allocated to 
a local IP address pool based upon IP address utilization. In more detail, utiUzation 
assessor 860 periodically assesses local IP address pool utilization. If DP address pool 
utilization exceeds a high watermark, utilization assessor interfaces with subnet requestor 
855 to request an additional subnet for the overutilized IP address pool. Subnet receiver 
870 receives a requested subnet and updates the corresponding local IP address pool and 
routing table. If IP address pool utihzation falls below a low watermark, utilization 
assessor 860 interfaces with subnet returner 865 to return a subnet, making it available 
for use by another edge router having an IP address pool associated with the same remote 
domain. 

[0053] Turning now to FIG. 9, a block diagram that illustrates the contents of a 
local IP address pool in accordance with one embodiment of the present invention is 
presented. The local IP address pool 900 includes the initial pool size 915, a high 
watermark 905 and a low watermark 910. The high watermark 905 indicates an upper 
limit on the number of IP addresses in use before another subnet is requested. The low 
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watermark 910 indicates a lower limit on the number of IP addresses in use before a 
subnet is released. 



[0054] The local IP address pool also includes an increase increment size 920 
and a decrease increment size 925. The increase increment size 920 indicates the number 
of IP addresses to request when IP address utilization exceeds the high watermark 905. 
The decrease increment size 925 indicates the number of addresses to release when the IP 
address utilization falls below the low watermark 910. 

[0055] The local IP address pool also includes the allocated subnets 935, an 
indication of which EP addresses are assigned 940 and the remote domain ID 930 
associated with the subnets in the local IP address pool. 

[0056] Tuming now to FIG, 10, a block diagram that illustrates the contents of a 
local IP address pool in accordance with one embodiment of the present invention is 
presented. The local IP address pool 1000 illustrated in FIG. 10 includes the fields 
indicated in FIG. 9. Additional fields include the subnet allocation protocol 1005, target 
servers 1010 and routing table ED 1015. The subnet allocation protocol 1005 may be, by 
way of example, RADIUS or DHCP. The target servers field 1010 indicates at least one 
server that includes the global IP address pool. The routing table ID 1015 identifies the 
routing table designated for the local EP address pool. 
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[0057] Turning now to FIG. 1 1 , a flow diagram that illustrates a method for on- 
demand IP address management in accordance with one embodiment of the present 
invention is presented. At 1 100, a global IP address pool and at least one local IP address 
pool are configured with per-remote domain subnet allocations. At 1 105, subnets are 
dynamically allocated between the global IP address pool and at least one local IP 
address pool based upon local IP address pool utilization. At 1 1 10, an unused IP address 
is allocated from a local IP address pool designated for a particular remote domain when 
an IP address request is received from a remote user. At 1 1 15, an IP address is 
deallocated back to its designated local IP address pool when a remote user relinquishes 
the IP address. This process of on-demand IP pool management continues at reference 
numeral 1105. 

[0058] Those of ordinary skill in the art will readily recognize that the acts 
Hsted in the process flow disclosed above do not have to be performed in a lock step 
manner with each other but may be performed independently. For example, dynamic 
allocation of subnets (1 105) may proceed at a rate independent from the rate at which EP 
addresses are allocated (1 110) or deallocated (1 115). 

[0059] Turning now to FIG. 12, a flow diagram that illustrates a method for 
configuring a global IP address pool and local IP address pools with per-remote domain 
subnet allocations in accordance with one embodiment of the present invention is 
presented. Figure 12 provides more detail for reference numeral 1 100 of FIG. 1 1. At 
1 200, the global EP address pool is configured with at least one block of EP addresses per 
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remote domain. Each block includes at least one subnet. At 1205, at least one local IP 
address pool in an edge router is configured for at least one remote domain supported by 
the edge router. At 1210, an initial subnet is requested for at least one local IP address 
pool. 

[0060] Turning now to FIG. 13, a flow diagram that illustrates a method for 
dynamically allocating and deallocating subnets between a global IP address pool and a 
local IP address pool based upon local IP address pool utilization in accordance with one 
embodiment of the present invention is presented. Figure 13 provides more detail for 
reference numeral 1 105 of FIG. 11. At 1300, a determination is made regarding whether 
a high watermark has been exceeded. If the high watermark has been exceeded, at 1305 
an additional subnet is requested. If the high watermark has not been exceeded, at 1310 a 
determination is made regarding whether a low watermark has been exceeded. If the low 
watermark has been exceeded, a subnet is relinquished at 13 15 and the summarized route 
for the subnet is removed from the corresponding routing table at 1320. If the low 
watermark has not been exceeded, at 1325 a determination is made regarding whether a 
requested subnet has been received. If the requested subnet has been received, at 1330 
the summarized route for the subnet is inserted into the corresponding routing table. 

[0061] According to one embodiment of the present invention, the size of a 
requested subnet is based upon the initial local IP address pool size. According to 
another embodiment of the present invention, the size of the requested subnet is based 
upon the current local IP address pool size. According to another embodiment of the 
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present invention, the size of a requested subnet is predetermined. The size of a released 
subnet may also be predetermined, relative to the initial local IP address pool size, or 
relative to the current local IP address pool size. 

[0062] Turning now to FIG. 14, a flow diagram that illustrates a method for 
dynamically allocating and deallocating subnets between a global IP address pool and a 
local EP address pool based upon local IP address pool utiUzation in accordance with one 
embodiment of the present invention is presented. Figure 14 provides more detail for 
reference numeral 1105 of FIG. 11. Figure His similar to FIG. 13, except with regard to 
receiving a requested subnet. When a requested subnet is received, at 1430 a 
determination is made regarding whether the received subnet size is less than the 
requested subnet size. If the received subnet size is less than the requested subnet size, a 
route for the subnet is inserted into the corresponding routing table at 1435 and another 
subnet is requested at 1440. 

[0063] If the received subnet size is not less than the requested subnet size, at 
] 445 a determination is made regarding whether the received subnet size is greater than 
the requested subnet size. If the received subnet size is greater than the requested subnet 
size, at 1450 a determination is made regarding whether the resulting local IP address 
pool utilization is less than the low watermark. If the resulting utilization is less than the 
low watermark, the received subnet is rejected at 1455 and another subnet is requested at 
1440. If the resulting local IP address pool utilization is not less than the low watermark, 
at 1460 a route for the subnet is inserted in the corresponding routing table. 
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[0064] While embodiments and applications of this invention have been shown 
and described, it would be apparent to those skilled in the art having the benefit of this 
disclosure that many more modifications than mentioned above are possible without 
departing from the inventive concepts herein. The invention, therefore, is not to be 
restricted except in the spirit of the appended claims. 
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